home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16081 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  4.3 KB
  1. Path: news.nyu.edu!schonberg!dewar
  2. From: dewar@cs.nyu.edu (Robert Dewar)
  3. Newsgroups: comp.lang.ada,comp.lang.c,comp.lang.c++,comp.edu
  4. Subject: Re: ANSI C and POSIX (was Re: C/C++ knocks the crap out of Ada)
  5. Date: 9 Apr 1996 08:14:06 -0400
  6. Organization: Courant Institute of Mathematical Sciences
  7. Message-ID: <dewar.829051685@schonberg>
  8. References: <JSA.96Feb16135027@organon.com> <dewar.828936837@schonberg> <4kb2j8$an0@solutions.solon.com> <dewar.829011320@schonberg> <4kcsnsINNgkb@keats.ugrad.cs.ubc.ca>
  9. NNTP-Posting-Host: schonberg.cs.nyu.edu
  10. X-Newsreader: NN version 6.5.0 (NOV)
  11.  
  12. Kazimir said:
  13.  
  14. >This is poor coding. You are _advertizing_ a buffer of size 1000, but passing a
  15. >pointer to a 100 byte buffer. It wouldn't even occur to me to do this, and
  16. >until now I have been completely oblivious to this difference between Linux
  17. >and other systems.
  18.  
  19.   The spec of an interface does not depend on what "wouldn't even occur"
  20.   to Kazimir, it must be independently defined.
  21.  
  22. >Unfortunately, I could not find anything in POSIX.1 that would explicitly
  23. >disallow this. The document is not very assertive in defining undefined
  24. >behavior. I'm going to check it once again in case I missed something.
  25.  
  26.   This is not a matter of defining undefined, it is a matter of defining
  27.   the requirement on the length of the read buffer, and it is truly
  28.   amazing to me that none of the references at hand, not even the POSIX
  29.   document, specifies this.
  30.  
  31. >It's not surprising: you lied to the read() function. But you are right, you
  32. >can't tell this from the definition in POSIX.1 or from typical manual pages.
  33.  
  34.   Sorry, this is wrong, I lied to the *implemention* of the function as
  35.   it occurred in Linux. Now it is true that the spec of the function is
  36.   different in Linux than in other systems (you quoted the manual pages
  37.   that showed this clearly). So of course we have a portability problem
  38.   here. Read is different in different systems, not only at the
  39.   implementation level, but at the spec level. The program in question
  40.   was correct with respect to the spec on "other systems":
  41.  
  42. >I checked the manual pages for read() on several systems. Linux documents
  43. >that results if the buffer pointed at by buf is outside of the address space
  44. >of the process. On other systems, it is claimed that EFAULT results if
  45. >the buf pointer is directed outside of the address space.
  46.  
  47.   Kazimir, perhaps you don't understand the whole idea of specs, but that
  48.   quote means that code that makes sure that the pointer is directed inside
  49.   the address space is OK if the buffer is not overrun!
  50.  
  51. >There are certain unwritten rules, though!
  52.  
  53.   That's the totally unacceptable viewpoint that is at the center of
  54.   the concerns in this thread (the details of read are uninteresting).
  55.   The trouble is of course that Kazimir's unwritten rules are clearly
  56.   different from other unwritten rules.
  57.  
  58.   I think one of the most essential things to understand in programming
  59.   is the importance of abstracting specifications from implementation.
  60.   Comments like the above (unwritten rules) one show that there is a
  61.   long way to go!
  62.  
  63. >What prevented the code from advertizing the true buffer size of 100?
  64. >In any case, it doesn't sound like a case of ``defensive programming''.
  65.  
  66.   Whoever said it was?
  67.  
  68.   With respect to the discussion of seperate processes adding to the
  69.   file etc, this is irrelevant to the discussion of the spec difference.
  70.   For the program in question, you still get a different behavior on
  71.   the two systems:
  72.  
  73.     On Linux, you always get an exception
  74.  
  75.     On "other systems", you get defined behavior, and no exception,
  76.     unless this unlikely external event lengthens the file, in which
  77.     case you get undefined behavior.
  78.  
  79.   These are quite different semantics, and it is different semantics that
  80.   result in one kind of portability problem.
  81.  
  82.   The observation about appending to the file is relevant in recommending
  83.   that the count reflect the actual count expected to be read, and of
  84.   course this was LONG ago corrected, within hours of finding the Linux
  85.   behavior, so I can't show you the incorrect code.
  86.  
  87.   But the fact remains that we have a portability problem which SHOULD be
  88.   cleared up by POSIX (or perhaps by SPEC1170), but apparently is not
  89.   mentioned by POSIX< and I am willing to bet that SPEC1170 is similiarly
  90.   vague. The standard of precision in defining specs of routines at this
  91.   level is generally appalling.
  92.  
  93.